Many businesses and organizations may utilize multiple services (e.g., software applications) that may be provided by different vendors. These services may be utilized in various ways, and may need to be executed concurrently, or as end-to-end processes. For example, a business may utilize a customer ordering service that may be utilized as an end-to-end service with a customer invoicing and billing service. For example, the customer ordering service may be supplied by a vendor that is different from a vendor supplying the customer invoicing and billing service, and the two services may be executed in different service environments, providing a composition of service environments. Further, a user may wish to utilize one or more customized services to be included in the end-to-end execution of other services.
Model-driven engineering and related concepts relate, for example, to the use of formalized models to design, manage, implement, and modify software applications and other processes. Such models provide a formalized abstraction of desired software properties and behaviors, and this abstraction provides, among other benefits, an ability of a designer or other user to understand, explain, create, or implement the software application(s) in a manner that is consistent, logical, and efficient. In theory, then, such development models may be modified as-needed to obtain a desired result. At times, however, it may be useful or desirable to use a development model that (in whole or in part) should not, or must not, be modified. For example, a developer may use a development model that is vendor-specific/vendor-confidential in whole or in part, and therefore the developer may not have the necessary levels of access to modify the development model. In another example, a user may use tools to extend a development model, e.g., to add functionality to an existing development model and associated software application. In such cases, it may be undesirable or impossible to modify some or all of the resulting, extended development model.
It may also be desirable to utilize various performance analysis tools on services to obtain information related to performance of the services, or to obtain service improvements or suggestions for improving the performance of the services. However, different types of performance analysis tools may be supported via different performance analysis engines. For example, discrete event simulation tools may provide decision support related to throughput and utilization of resources, while layered network analysis may be provided by a different tool. This type of performance analysis may become very difficult in attempting to analyze performance of a complex service composition.
It is possible to modify development models (e.g., to modify associated development meta-models) to add annotations which may be used to better understand or implement the development models. For example, such annotations may be related to a desired performance or security level(s) of the development model, or individual elements thereof. However, in the cases such as those just mentioned where the services may be provided within several different service environments, it may be difficult or impossible to add such annotations to gain the advantages related thereto, for example, sophisticated performance related decision support which takes different service environments into account in order to provide end-to-end decision support for service compositions.